<html>
<head>
<title>Project 3 </title>
</head>
<body bgcolor="#ffffff">
<h1 align="center">Project 3 </h1>
<p>
<b>Due Date</b>:  Mar 25, by midnight.
</p>
<p>
[<b>Important Note</b>: If you are reading the <a href="./prj3.umt">./prj3.umt</a> version of this
document, please be aware of the fact that it is really the source code for
the <tt>HTML</tt> <a href="./prj3.html">./prj3.html</a> and <tt>PDF</tt> <a href="./prj3.pdf">./prj3.pdf</a> versions.  Hence it
contains markup; usually the markup is quite unobstrusive, but sometimes it
gets in the way.  In particular, some <tt>*</tt>'s and quotes may not make sense as
they are also used for markup.]
</p>
<p>
The document first describes the aims of this project.  It then gives the
requirements as explicitly as possible.  It describes the files which are
being provided and hints at how the project may be implemented.  Finally, it
lists exactly what needs to be submitted.
</p>
<h2>Aims</h2>
<p>
The aims of this project are as follows:
</p>
<ul>
<p><li>
To introduce you to using dynamic loading under Unix.
</p>
<p><li>
To get you to write client-server programs using FIFOs as a IPC mechanism.
</p>
</ul>
<h2>Requirements</h2>
<p>
Write a server program with executable <tt>quadrd</tt> and a client program
with executable <tt>quadrc</tt>.  The server program <tt>quadrd</tt> when invoked as
</p>
<pre>
   $ ./quadrd DIR
</pre>
<p>
should create a concurrent server daemon running in directory <tt>DIR</tt>.  After
starting the daemon, the process started from the command-line should print
out the daemon's PID on standard output followed by a newline and exit.  The
started daemon should allow quadr clients to evaluate integrals using
trapezoidal quadrature. The function being integrated must be loaded
dynamically by the daemon from a library file having the same name as the
function.  Each client should be handled using a separate concurrent
worker process (using the double-fork technique to avoid zombies), with a
single worker process handling all requests from a specific client.
</p>
<p>
The client program is invoked as:
</p>
<pre>
   $ ./quadrc DIR
</pre>
<p>
where <tt>DIR</tt> is the directory where the server is running.
</p>
<p>
The I/O behavior of the client should be identical to that specified in <a href="../prj1/prj1.html">prj1</a>.  After validating the input, the quadr client should
send the input to the quadr daemon using a agreed upon protocol and then
print out the result returned by the server on stdout as in prj1.
</p>
<p>
All communication between clients and the server is to be performed using
FIFOs.  The details of the design of the communication protocol are left
entirely to you.
</p>
<h2>Provided Files</h2>
<p>
The <a href="./files/">./files/</a> directory contains the following files:
</p>
<dl>
<p><dt><a href="./files/Makefile">Makefile</a><dd>
    This file can be used to build your project.  Assuming that all your
    client source code in <tt>quadrc.c</tt>, server source code is within a
    single file <tt>quadrd.c</tt>, and common definitions in <tt>quadrdefs.h</tt>, then
    typing <tt>make</tt> will compile all your code and link into <tt>quadrc</tt> and
    <tt>quadrd</tt> executables.  You may modify the <tt>Makefile</tt> to meet the needs
    of your individual project.
</p>
<p><dt><a href="./files/quadrdefs.h">quadrdefs.h</a><dd>
    Common definitions shared between client and server.  Any additional
    definitions shared between client and server (like protocol parameters)
    may be added to this file.
</p>
<p><dt><a href="./files/test.c">test.c</a><dd>
    A test program which illustrates the use of dynamically loaded
    modules to evaluate the dynamically loaded function specified by its
    first argument at the argument specified by its second argument.  It can
    be built by using the <tt>TEST</tt> target in the above <a href="./files/Makefile">Makefile</a>.  It's use is shown in the following log:
</p>
<pre>
    $ make TEST
    gcc -ldl -lm  test.o   -o test
    gcc -g -Wall --std=c99 -fpic -shared sinFn.c -o sinFn
    gcc -g -Wall --std=c99 -fpic -shared wikipediaFn.c -o wikipediaFn
    $ LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./test sinFn 0.7853975
    0.707106
    $
</pre>
</dl>
<h2>Caution</h2>
<p>
<b>IMPORTANT</b>: In this project, you will be creating multiple processes as
well as daemon processes.  It is important that you ensure that you do not
create runaway processes and that you clean up any garbage processes
periodically and definitely before you logout.  So use the same commands as
you used in <a href="../prj2/prj2.html">prj2</a> to ensure that you clean up.
</p>
<p>
Note that by definition, a daemon will survive your logging out, so it is
particularly important to specifically clean them up.
</p>
<h2>Discussion</h2>
<p>
You will need to decide on the details of the communication protocol between
the quadrd server and quadrc clients.  These decisions involve multiple
aspects:
</p>
<ol type="1">
<p><li>
The FIFOs used for the IPC.  There will need to be a well-known FIFO
     known by the clients and the server which can be used by clients to
     establish the initial contact with the server, but there can be
     variants on client-specific FIFOs:
<ul>
<p><li>
Can the well-known FIFO also be used for sending quadrature requests
        to the server or should there be client-specific FIFOs used for
        sending the requests.  Consider the tradeoffs between these
        approaches.
</p>
<p><li>
Can a single FIFO be used for sending all results back to all
        clients or should there be a client-specific FIFO used to send back
        results to a specific client.
</p>
</ul>
</p>
<p><li>
Given a decision on the number and lifetime of the IPC FIFOs, how will
     data be sent across the FIFOs?  Text or binary?  How is the end of a
     request or response delimited?
</p>
<p><li>
How does the server know about the termination of a client so that the
     worker process can terminate?  How can termination of a client lead to
     cleanup of all client-specific FIFOs (if any).
</p>
</ol>
<h2>Hints</h2>
<p>
The following steps are not prescriptive:
</p>
<ol type="0">
<p><li>
Review the material on dynamic linking, daemons, and FIFOs.
      Design the protocol for communication between the client
      and server.
</p>
<p><li>
Start with the test program as a base for the daemon.
      It is setup to merely evaluate a dynamically loaded function at
      a specified argument.  Change it to integrate a dynamically loaded
      function over a range specified by command-line arguments.
</p>
<p><li>
Change the program from the previous step to get inputs from
      a FILE stream defaulting to stdin and write quadrature results
      to a FILE stream defaulting to stdout.
</p>
<p><li>
Modify your program from the previous step to become a daemon setup to
      communicate with the client as per the protocol you designed in the
      initial step.
</p>
<p><li>
Depending on the details of your protocol, you may be able to test the
      daemon by using <tt>echo</tt> to send a request to a FIFO.  You can observe
      the reaction of the daemon to the request using a debugger or print
      statements.
</p>
<p><li>
Write your client program.
</p>
<p><li>
Test the client versus the daemon.
</p>
<p><li>
Iterate the previous steps until your program meets all the
      specifications.
</p>
</ol>
<h2>Submission</h2>
<p>
You should submit a archive <tt>prj3.tar.gz</tt> which contains all the source
files needed to build your project.
</p>
<ul>
<p><li>
The archive should not contain any executable or object files.
</p>
<p><li>
The provided <a href="./files/Makefile">Makefile</a> contains a <tt>submit</tt>
    target such that typing <tt>make submit</tt> will build the required
    <tt>prj3.tar.gz</tt> archive.  This presupposes that you have edited the
    <tt>Makefile</tt> to adjust it if you have a different organization for your
    source files than that outlined above.
</p>
<p><li>
The archive <b>must</b> contain a <tt>Makefile</tt> such that typing <tt>make</tt> in the
    directory containing the unpacked archive should build your project's
    main executable <tt>prj3</tt>.  You can test this before submission, by
    unpacking your archive into an empty directory and checking to see
    whether typing <tt>make</tt> builds correctly.
</p>
<p><li>
Your submission <b>must</b> include a <tt>README</tt> file which minimally contains
    at least your name and ID number.  It can optionally contain any
    comments you feel are relevant to the project like what works, what does
    not work, what you feel is neat, logs of test cases, etc.
</p>
<p><li>
Your submission should include any files from the <a href="./files">./files</a> directory
    your project uses, whether you modified them or not.  You will not need
    to modify the <tt>Makefile</tt> if you use exactly the same names and
    organization as that in the provided <a href="./files/Makefile">Makefile</a>.
</p>
<p><li>
You do not need to include any files used from the <tt>cs551s10</tt> library.
</p>
</ul>
<p>
The above archive should be email'd as an attachment to the TA at
<a href="mailto:ruiqi.luo@gmail.com">mailto:ruiqi.luo@gmail.com</a> with subject set to <tt>CS 451/551 Project 3</tt>.  If
you discover a mistake in your submitted project before the due date, you
may submit it again; only the latest submission will be graded.
</p>
</body>
</html>
